QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930261.txt

Internet Message Format | 1994-06-04 | 11KB

Date: Fri,  8 Oct 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #261
To: tcp-group-digest


TCP-Group Digest            Fri,  8 Oct 93       Volume 93 : Issue  261

Today's Topics:
                     KA9Q SMTP... (& SMTP spec..)
                        Raising the S/N ratio
                          SMTP transparency

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 07 Oct 93 10:02 PDT
From: Michael Stein                        <[e-mail]>
Subject: KA9Q SMTP... (& SMTP spec..)
To: [e-mail]

By my reading of the SMTP specs, the null character ' 0'
(or 0x00) is valid in the user data.  So SMTP data can't
be processed as C strings without loosing the tail ends
of lines...

------------------------------

Date: Thu, 7 Oct 93 08:41:10 EST
From: "Ashok Aiyar" <[e-mail]>
Subject: Raising the S/N ratio
To: [e-mail]

On Wed, 6 Oct 93 23:46:05 EDT, Ross Patterson wrote:

>
>     else if (*p != '.')
>           p--;
>
>thus removing the first of a pair of periods that start a line (i.e.
>"<CRLF>..").
>
>Note: The above suggestions are untested.  That would be cheating.
>Software is a thing of the mind.

:-)

Works very well.  Thanks!

Ashok

--
Ashok Aiyar                        Email: [e-mail]
Department of Biochemistry           Tel: [phone]
CWRU School of Medicine              Fax: [phone]
MIME Enclosures OK

------------------------------

Date: Fri, 8 Oct 93 01:06:38 EDT
From: "Barry Siegfried" <[e-mail]>
Subject: SMTP transparency
To: [e-mail]

Hi, all...

Regarding the fix to the SMTP server which Ross Patterson, N4YYH
provided to delete the leading dot on any line beginning with two
dots, I have a somewhat different analysis of the problem, and I'd
like to offer what I've come with to the group.

I'm the first to admit that I am no expert in interpreting RFCs, so
my premise might be faulty.  But here goes anyway...

Again reading page 41, section 4.5.2 of RFC 821 on SMTP dot handling
(as quoted by Ross):

   "2. When a line of mail text is received by the receiver-SMTP it
    checks the line.  If the line is composed of a single period it
    is the end of mail.  If the first character is a period and there
    are other characters on the line, the first character is deleted."

(Note that the above doesn't specify just precisely where this first
dot character comes from, that is, was it originally in the mail, or
was it put there by the sending SMTP client?)

and,

again reading page 55, section 5.2.11 of RFC 1123 "Transparency:
RFC-821 Section 4.5.2" (as quoted by Ross):

   "Implementors MUST be sure that their mail systems ALWAYS add and
    delete periods to ENSURE MAIL TRANSPARENCY."  (my emphasis added)

I interpret this to mean, as Ross did:

> It's not just the extra period - it's any leading (but not standalone)
> period.  A conforming sender-SMTP will ALWAYS (my emphasis) send doubled
> leading periods, but the spec is clear that the leading period gets
> removed regardless of what follows it.  The sole exception is the
> "<CRLF>.<CRLF>" end-of-mail sequence.

But why not a stand alone dot?  If I deliberately put a stand alone dot,
or multiple dots at the beginning of lines in my messages, I want them
delivered to the other end precisely the way I entered them (therein
the definition of "transparency").

Upon checking just precisely what the original code in the SMTP server
does, I came up with these results:

Original code
-------------
        else if (!(*p == '.' && *(p+1) == '\0'))
                p--;

Definition
----------
Delete the first dot on a line if it is immediately followed by a
second dot, and then a CRLF.

Results:

 Sent line                        Received line
 ---------                        -------------
 .<any other data><CRLF>    -->  .<any other data><CRLF>
 .<CRLF>                    -->  .<CRLF>

 ..<any other data><CRLF>   -->  ..<any other data><CRLF>
 ..<CRLF>                   -->  .<CRLF>  <-- this case only is reduced !

 ...<any other data><CRLF>  -->  ...<any other data><CRLF>
 ...<CRLF>                  -->  ...<CRLF>

etc.

Note that the reason this one case above gets reduced by one dot,
and the others don't, is because the SMTP server has no way of
determining whether the two dots comprising that single line are
there as a result of being originally placed in the message, or
whether they exist because the SMTP client added a dot in a line
containing only a single dot!

Now, in contrast to the original code, the N4YYH revised code in the
SMTP server will give these results:

N4YYH code
----------
        else if (*p != '.')
                p--;

Definition
----------
Delete the first dot on a line if it is immediately followed by a
second dot (no other requirement).

Results:

 Sent line                        Received line
 ---------                        -------------
 .<any other data><CRLF>    -->  .<any other data><CRLF>
 .<CRLF>                    -->  .<CRLF>

(every case below is reduced by one dot) !

 ..<any other data><CRLF>   -->  .<any other data><CRLF>
 ..<CRLF>                   -->  .<CRLF>

 ...<any other data><CRLF>  -->  ..<any other data><CRLF>
 ...<CRLF>                  -->  ..<CRLF>

etc.

Actually, Ross was on the right track when he said:

> It would seem the thing to do is to delete:
>
>       else if (!(*p == '.' && *(p+1) == '\0'))
>               p--;
>
> thus removing any period that starts a line (i.e. "<CRLF>.").

And that's probably where he should have stopped, since a careful
examination of the problem will indicate that the problem is
actually elsewhere!

Here's my take on this:

An examination of the corresponding code in the SMTP client indicates
that a dot is added only to lines that consist of a single dot,
followed by <CRLF>, and that is where the REAL problem is !

What is needed in concert with deletion of the code above in the SMTP
server, is a corresponding fix to the SMTP client to make sure that an
extra dot is ALWAYS added to any line beginning with a dot, regardless
of whatever other data follows it, which will then ALWAYS be removed
by the SMTP server (again, therein the definition of "transparency").
The combination of these two operations, will then cause all lines
beginning with dots to be passed "transparently" from SMTP client
to server, and all original dots at the beginnings of lines will be
preserved in messages.

So, in contrast to what Ross did, here are the corresponding code
fragments which I have implemented in my own copies of SMTPSERV.C
and SMTPCLI.C:

SMTPSERV.C
----------
static int
getmsgtxt(mp)
struct smtpsv *mp;

        /* Check for end of message i.e. a "." or escaped ".." */
        if (*p == '.') {

                /* This IS the end of the message (i.e.
                 * "<CRLF>.<CRLF>") - K2MF 10/93
                if (*++p == '\0') {

                        << End of message routines execute here >>

                        return 0;

                /* This IS NOT the end of message - K2MF 10/93 */

                /* Original code - this removes the first dot on any
                 * line consisting solely of two dots (i.e.
                 * "<CRLF>..<CRLF>") - This is not transparent ! -
                 * K2MF - 10/93
                } else if (!(*p == '.' && *(p+1) == '\0')) */

                /* N4YYH mod - this removes the first dot on any line
                 * beginning with two dots regardless of what follows
                 * (i.e. "<CRLF>..<any other data><CRLF>") - This is
                 * not transparent ! - K2MF 10/93
                } else if (*p != '.') */

                /* Since the SMTP client is required to make the mail
                 * "transparent", and to insert an extra dot in front
                 * of the first character on any line which begins
                 * with a dot, it is best to simply drop the first
                 * dot, because by definition, the SMTP client has
                 * inserted it in front of an existing dot (see the
                 * corresponding fix to smtpsendfile() in SMTPCLI.C)
                 * - K2MF 10/93
                        p--; */
  }
        }
        << continue >>

SMTPCLI.C
---------
static int
smtpsendfile(cb)
register struct smtpcli *cb;

        /* Escape a single '.' character at the beginning of a line */

        /* Original code - this inserts a dot on any line consisting
         * solely of one dot (i.e. "<CRLF>.<CRLF>") - This is not
         * transparent ! - K2MF 10/93
        if(strcmp(cb->buf,".\n") == 0) */

        /* Since the SMTP client is required to make the mail
         * "transparent", and to insert an extra dot in front
         * of the first character on any line which begins with
         * a dot, it is best to insert a dot on any line which
         * begins with a dot (see the corresponding fix to
         * getmsgtxt() in SMTPSERV.C) - K2MF 10/93 */
        if(*(cb->buf) == '.')

                usputc(cb->s,'.');
        usputs(cb->s,cb->buf);

<< continue >>

Definition
----------
The SMTP client will always add a dot in any line which begins
with a dot, and the SMTP server will always delete the first
character of a line if it is a dot.

This would seem to preserve "transparency".

Now of course, until all NOS SMTP clients and servers have these
mods in them, when a modified SMTP client talks to an unmodified
SMTP server, most lines beginning with a dot will have an extra
dot in the received message, and, when an unmodified SMTP client
talks to a modified SMTP server, most lines beginning with a dot
will be reduced by one dot in the received message.

73, de Barry, K2MF >>

^________________________________]
^      Barry Siegfried, K2MF     ]
^   AmprNet: [e-mail]  ]
^  InterNet: [e-mail]  ]
^\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\]

------------------------------

End of TCP-Group Digest V93 #261
******************************
******************************